Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 2/csmp-v2-010.txt

Text File | 1994-12-08 | 48.9 KB | 1,229 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sun, 07 Feb 93       Volume 2 : Issue 10

Today's Topics:

    Distinguishing FrontClicks?
    Uniquely identifying a Mac? How?



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you can
post articles to any newsgroup by mailing your article to
    [e-mail]
So, to post an article to comp.sys.mac.programmer, mail your article to
    [e-mail]
Note the '-' instead of '.' in the newsgroup name.  Be sure to ask that
replies be emailed to you instead of posted to the group, and give your
email address.

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Michael Hecht)
Subject: Distinguishing FrontClicks?
Date: 23 Dec 92 16:07:49 GMT
Organization: SAS Institute Inc.

Hello!

I turned on the getFrontClicks bit in my SIZE resource, because it makes
sense for my application. However, I don't want *all* parts of the window
to respond to layer-changing clicks. How can I distinguish a click that
changes my layer from other clicks?

I can't just assume the next click after a resume event is a frontClick,
since the user may have switched to me via the application menu or by
double-clicking my Finder icon. For all I know, some other app may have
called SetFrontProcess for me! Just throwing out the next click would
probably frustrate the user (me) in these cases.

The best method I could think of is to use EventAvail to look for
mouseDown events in my resume event handler. If I see one I'll set a flag
that I can look at in my mouseDown handler. Is this a reliable method?

What I'd prefer is something along the lines of an event modifiers flag
on the mouseDown that says "this event caused you to switch layers."

Thanks!
- --Michael

=======================================================================
Michael P. Hecht                 | Internet:  [e-mail]
SAS Institute Inc.; Cary, NC USA | AppleLink: SAS.HECHT

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: 3 Jan 93 22:40:14 GMT
Organization: MacDTS Marauders

In article <[e-mail]>, Michael Hecht
<[e-mail]> wrote:
>
> Hello!
>
> I turned on the getFrontClicks bit in my SIZE resource, because it makes
> sense for my application. However, I don't want *all* parts of the window
> to respond to layer-changing clicks. How can I distinguish a click that
> changes my layer from other clicks?

A technique that's worked for me is to compare the 'when' fields of the
click and the resume event; if the mouseDown has a time before the
resume event, then it's probably this click that caused you to be switched.
(The exception would be if the user had posted several events, which got
queued up because [Get|Wait]NextEvent wasn't being called often enough;
for example, if I have an INIT which switches layers when I hit a hot key
installed, and I type the hot key, then click, the click won't have caused
the switch, but it will seem like it had.)

Specifically, when you get a resume, remember the value in the "when"
field;
when you get the first mouseDown after the resume, check its when; if it
was posted before the resume (or at the same time), consider it to be the
click that brought you forward.

Official sounding warning: this is only a side effect of the way the
process manager works now.  Don't count on it continuing to work this way,
it's not a documented feature.  If you want to use it, make sure you're
willing to accept the ways in which it might break (unreliable detection
of clicks which bring the layer to the front).

Enjoy,
Tim Dierks
MacDTS, but I speak for myself and my Albert Einstein doll

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Organization: Taligent
Date: Mon, 4 Jan 1993 04:53:53 GMT

In article <[e-mail]>, [e-mail]
(Tim Dierks, software saboteur) wrote:
>
> Tim Dierks
> MacDTS, but I speak for myself and my Albert Einstein doll

Hmm...looks like DTS still has that x-mas gift swap at the end of the
year...

- -----
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Eric Schlegel)
Date: 4 Jan 93 16:08:43 GMT
Organization: Microsoft Corporation

In article <[e-mail]> [e-mail]
(Tim Dierks, software saboteur) writes:
>In article <[e-mail]>, Michael Hecht
><[e-mail]> wrote:
>>
>> I turned on the getFrontClicks bit in my SIZE resource, because it makes
>> sense for my application. However, I don't want *all* parts of the window
>> to respond to layer-changing clicks. How can I distinguish a click that
>> changes my layer from other clicks?
>
>A technique that's worked for me is to compare the 'when' fields of the
>click and the resume event; if the mouseDown has a time before the
>resume event, then it's probably this click that caused you to be switched.

Wow, I know something that Tim doesn't... :) I've never actually used this,
but according to IM 6, pg. 5-16, the activeFlag bit in the modifiers field
of a mouseDown event will be set if the mouseDown caused your layer to become
frontmost. Also see pg. 2-20 in IM:Mac Toolbox Essentials. Note that this is
a System 7-specific feature - it won't work for MultiFinder under System 6.

- -eric
- -----
My opinions, not Microsoft's.

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: Tue, 5 Jan 1993 22:57:25 GMT
Organization: MacDTS Marauders

In article <[e-mail]>, [e-mail]
(Eric Schlegel) wrote:
>
> In article <[e-mail]> [e-mail]
> (Tim Dierks, software saboteur) writes:
> >In article <[e-mail]>, Michael Hecht
> ><[e-mail]> wrote:
> >>
> >> I turned on the getFrontClicks bit in my SIZE resource, because it makes
> >> sense for my application. However, I don't want *all* parts of the window
> >> to respond to layer-changing clicks. How can I distinguish a click that
> >> changes my layer from other clicks?
> >
> >A technique that's worked for me is to compare the 'when' fields of the
> >click and the resume event; if the mouseDown has a time before the
> >resume event, then it's probably this click that caused you to be switched.
>
> Wow, I know something that Tim doesn't... :) I've never actually used this,
> but according to IM 6, pg. 5-16, the activeFlag bit in the modifiers field
> of a mouseDown event will be set if the mouseDown caused your layer to become
> frontmost. Also see pg. 2-20 in IM:Mac Toolbox Essentials. Note that this is
> a System 7-specific feature - it won't work for MultiFinder under System 6.
>
> -eric
> -----
> My opinions, not Microsoft's.

Cool!  Just goes to show that Inside Mac VI is bigger than you
can possibly imagine....

Tim Dierks
MacDTS, but I speak for myself

Drop by and say 'Hi' at MacWorld- DTS Debugging Lab, I'll be there
Thursday morning and Friday afternoon.

---------------------------

From: [e-mail] (Michael Trevor CUTTER)
Subject: Uniquely identifying a Mac? How?
Date: 14 Dec 92 23:34:35 GMT
Organization: Computer Science, University of Melbourne, Australia

We are looking for a way to uniquely identify a Mac, probably one on a network,
but not necessarily. Is the serial number or similar available somewhere in the
ROMs or parameter RAM? (Highly unlikely, I know - specially since PRAM can be
reset)

We are considering assigning each mac a unique chooser name then disabling the
Sharing Setup Control panel...this is the best solution so far.

Any assistance would be wonderful.

Regards,
    Mike.
- --
Michael Cutter                        email: [e-mail]
Ictinus Network Development Team             [e-mail]
BCAT Development Team                 snail: c/- 3 Barton Street
Department of Architecture & Building        Hawthorn, VIC, 3122
University of Melbourne, Australia           AUSTRALIA
Sort of 3rd Year Computer Scientist   phail: 61-3-853 9717

+++++++++++++++++++++++++++

From: [e-mail] (Mats Bredell)
Date: 15 Dec 92 14:11:28 GMT
Organization: Uppsala University Computing Center (UDAC)

Michael Trevor CUTTER ([e-mail]) wrote:
: We are looking for a way to uniquely identify a Mac, probably one on a network,
: but not necessarily. Is the serial number or similar available somewhere in the
: ROMs or parameter RAM? (Highly unlikely, I know - specially since PRAM can be
: reset)
:
: We are considering assigning each mac a unique chooser name then disabling the
: Sharing Setup Control panel...this is the best solution so far.
:
: Any assistance would be wonderful.

I also need to solve this problem for a program I'm writing. I've considered
two possibilities:

  1. If there's an ethernet card, use the ethernet address.
  2. Use the creation date/time of the harddisk or system folder or something
     similar.

This method will work as long as the user is not reconfiguring the system or
reformating the harddisk. This is not a problem in my case, since it will
"only" force the user to reconfigure the application in my case.

/Mats
- --
Mats Bredell                                   [e-mail]
Uppsala University Computing Center (UDAC)     Ph:  [phone]
Department of medical systems                  Fax: [phone]
Sweden                                         Think straight - be gay!

+++++++++++++++++++++++++++

From: [e-mail] (Jon Wtte)
Date: 15 Dec 92 12:17:56 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In <[e-mail]> [e-mail] (Michael Trevor CUTTER) writes:

>We are looking for a way to uniquely identify a Mac, probably one on a network,
>but not necessarily. Is the serial number or similar available somewhere in the
>ROMs or parameter RAM? (Highly unlikely, I know - specially since PRAM can be
>reset)

The ROMs are masked, so doing them unique would be a trifle expensive :-)
(You could do it by burning wit a laser)

>We are considering assigning each mac a unique chooser name then disabling the
>Sharing Setup Control panel...this is the best solution so far.

If you run MacTCP, each mac will have/get its own IP address;
likewise, EtherNet cards have a 6-byte EtherNet address that's
unique in the world.

- --
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --
   The word "politics" is derived from the word "poly", meaning
   "many", and the word "ticks", meaning "blood sucking parasites".
                     -- Larry Hardiman

+++++++++++++++++++++++++++

From: [e-mail] (Roy Smith)
Date: 16 Dec 92 02:16:56 GMT
Organization: New York University, School of Medicine

[e-mail] (Jon Wtte) writes:
>If you run MacTCP, each mac will have/get its own IP address;
>likewise, EtherNet cards have a 6-byte EtherNet address that's
>unique in the world.

    Well, no, that's not quite true.  If you run MacTCP, you basically
have 3 choices:

    1) You're configured for "Manual" mode, in which case the only
reason you have an unique IP address is because somebody (manually, hence
the name) configured it in.  That somebody could just as easily change it,
either by accident, or on purpose.

    2) You're on a LocalTalk segment behind a FastPath (or similar box
with KIP-like dynamic address allocation) and you're configured for "Server"
moded.  In that case, you've got an IP address which is currently unique,
but each time you reboot, you (potentially) get a different one.  Hardly
useful for identifying a machine on the network.

    3) You're on Ethernet and configured for "Server" mode, in which
case a bootp server gave you your IP address, based on a 1-to-1 mapping from
your ethernet address.  I don't know about token ring, but presumably the
same thing can happen with TokenTalk.

    Then, of course, there's "Dynamic" mode in MacTCP, but I havn't the
foggiest idea what it is. :-)

    Unfortunately, as far as I can tell, unless your Mac has an ethernet
(or, presumably, token ring) port, there is no built-in unique way to
identify the machine.  I personally think it was a major mistake for Apple
to not have put some sort of machine-readable serial number in each machine.
Actually, there is a machine-readable serial number *on* each machine; it's
the bar-code label on the bottom/back/where-ever.  Unfortunately, since most
Macs don't come with bar-code readers, they have no way of finding out their
own serial number.  Sort of like walking around with a sign painted on your
forehead that everybody but yourself can read!  Obviously, it would have
added something to the manufacturing costs, but slapping those unique
bar-code labels must cost something too; I would have been happy to give up
the unique bar-code on my keyboard and mouse to have a serial number burned
into an eprom on board.

- --
Roy Smith <[e-mail]>
Hippocrates Project, Department of Microbiology, Coles 202
NYU School of Medicine, 550 First Avenue, New York, NY 10016
"This never happened to Bart Simpson."

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Date: 16 Dec 92 15:49:37 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] (Roy Smith) writes:
>    Unfortunately, as far as I can tell, unless your Mac has an ethernet
>(or, presumably, token ring) port, there is no built-in unique way to
>identify the machine.  I personally think it was a major mistake for Apple
>to not have put some sort of machine-readable serial number in each machine.
[]

Apple's Lisa computers each had a software-accessable serial number.  This was
mostly used for copy-protecting software, including the OS.  Ick.


- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g++ k s++ e+ h- pv    |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: 16 Dec 92 18:02:49 GMT
Organization: MacDTS Marauders

In article <[e-mail]>, [e-mail] (Roy
Smith) wrote:
>
> [e-mail] (Jon Wtte) writes:
> >If you run MacTCP, each mac will have/get its own IP address;
> >likewise, EtherNet cards have a 6-byte EtherNet address that's
> >unique in the world.

[ Stuff about MacTCP configurations ]

>     Unfortunately, as far as I can tell, unless your Mac has an ethernet
> (or, presumably, token ring) port, there is no built-in unique way to
> identify the machine.  I personally think it was a major mistake for Apple
> to not have put some sort of machine-readable serial number in each machine.

Well, the Lisa had a unique serial number in each machine; as I
understand, it was burned into a special PROM on the motherboard.
This was a major headache at the time, which is why it wasn't
continued in the Mac.  The biggest single problem was serviceing
these machines; if the PROM blew, you had to special-order a
PROM that matched the one that had been destroyed (or all your
copy-protected software wouldn't work anymore) or have to go and
tell a number of software companies that your PROM blew so you need
a new unlocked copy of their program.  If something else on the
machine broke, or you wanted to upgrade, and you wanted to swap
motherboards, you had to deal with swapping the serial PROMs too.

In the end it was much more trouble than it was worth, and its
only real purpose was copy-protection, and copy-protection is
generally easily worked around, so it was taken out of the Mac.

Tim Dierks
MacDTS, but today my shoes match!

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 17 Dec 92 16:28:20 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Roy Smith) writes:
>
> I personally think it was a major mistake for Apple
> to not have put some sort of machine-readable serial number in each machine.

The trouble with providing a feature like that is that people will start to
use it.

Can you say "copy protection"...?

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

+++++++++++++++++++++++++++

From: [e-mail] (Edgar Matias)
Date: 17 Dec 92 15:58:13 GMT
Organization: CSRI, University of Toronto


> In article <[e-mail]>, [e-mail] (Roy Smith) writes:
> >
> > I personally think it was a major mistake for Apple
> > to not have put some sort of machine-readable serial number in each machine.
>
> The trouble with providing a feature like that is that people will start to
> use it.
>
> Can you say "copy protection"...?
>
> Lawrence D'Oliveiro                       fone: [phone]


Isn't that the idea?  If you are going to have a copy protection scheme,
I'd think that would be the best type.  Least amount of hassle for the
user, yet still protects the software industry's interests.  Of course,
if you're in the habit of pirating software maybe it's not in your
interests...

I'm a little surprised that the software industry hasn't latched onto
this idea and lobbied hard for it.  It seems like the ideal solution
to software piracy.  Of course, it wouldn't stop piracy entirely but
it would certainly put a serious dent in it.

Edgar
- --
Edgar Matias
Input Research Group
University of Toronto
- --
I speak for no one...

+++++++++++++++++++++++++++

From: [e-mail] (Dana S Emery)
Date: 17 Dec 92 22:42:58 GMT
Organization: personal

In article <[e-mail]>,
[e-mail] (Edgar Matias) wrote:
>
>
> > In article <[e-mail]>, [e-mail] (Roy Smith) writes:
> > >
> > > I personally think it was a major mistake for Apple
> > > to not have put some sort of machine-readable serial number in each machine.
> >
> > The trouble with providing a feature like that is that people will start to
> > use it.
> >
> > Can you say "copy protection"...?
> >
> > Lawrence D'Oliveiro                       fone: [phone]
>
>
> Isn't that the idea?  If you are going to have a copy protection scheme,
> I'd think that would be the best type.  Least amount of hassle for the
> user, yet still protects the software industry's interests.  Of course,
> if you're in the habit of pirating software maybe it's not in your
> interests...
>
> I'm a little surprised that the software industry hasn't latched onto
> this idea and lobbied hard for it.  It seems like the ideal solution
> to software piracy.  Of course, it wouldn't stop piracy entirely but
> it would certainly put a serious dent in it.


OK, now that would either be in a custom chip or in the Roms, but in either
case it would be WELDED on to the logic board, right?

Now what happens when a logic board needs service?  Since the board now
must stay with the machine, you have just forced all apple dealers to
perform componant level diagnosis and repair, this is a dramatic change
from present policy, and on which APple is likely to regard as a giant step
backward.

Oh, and just how would one deal with a faulty Rom chip, or a ROM upgrade
(remember the SCSI problems in the first and second versions of the 128k
roms?).
- --

Dana S Emery <[e-mail]>

+++++++++++++++++++++++++++

From: [e-mail] (Edgar Matias)
Date: 18 Dec 92 03:32:00 GMT
Organization: CSRI, University of Toronto


> OK, now that would either be in a custom chip or in the Roms, but in
> either case it would be WELDED on to the logic board, right?
>

No, it would be in a socket.  That way, if you had to swap for a new
board you could simply pull it out of the old board and stick it in
the new one.  No wielding required.

Edgar
- --
Edgar Matias
Input Research Group
University of Toronto
- --
I speak for no one...

+++++++++++++++++++++++++++

From: [e-mail] (John Griswold)
Organization: Bentley Systems (Development)
Date: Fri, 18 Dec 1992 14:51:09 GMT

In article <[e-mail]>,
[e-mail] (Edgar Matias) wrote:
>
>
> > OK, now that would either be in a custom chip or in the Roms, but in
> > either case it would be WELDED on to the logic board, right?
> >
>
> No, it would be in a socket.  That way, if you had to swap for a new
> board you could simply pull it out of the old board and stick it in
> the new one.  No wielding required.
>

And what happens when I upgrade my machine (like I just recently did).  Do
I have to go and buy all new software.  Forget that, I will deal with
software companies that can deal with *real* users.  If you have to deal
with some form of hardware lock I would prefer the dongle approach.  You
know those little inline boxes that can hang off of the ADB.  But I prefer
to not even deal with that.

- --------------------------------------------+---------------------------
John Griswold                               | Bentley Systems Inc.
UUCP: ...uunet!ingr!bntley!griswoldj        | 690 Pennsylvania Drive
INTERNET: [e-mail]  | Eagleview Corporate Center
AT&T:     [phone]                    | Exton, PA 19341
- --------------------------------------------+---------------------------

+++++++++++++++++++++++++++

Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Fri, 18 Dec 1992 14:52:47 GMT

In <[e-mail]> [e-mail] (Edgar Matias) writes:

>> > I personally think it was a major mistake for Apple
>> > to not have put some sort of machine-readable serial number in each machine.
>> The trouble with providing a feature like that is that people will start to
>> use it.

>I'd think that would be the best type.  Least amount of hassle for the
>user, yet still protects the software industry's interests.  Of course,

Copy protection sucks. ALWAYS.

What if you have to have a logic board replacement? Or a copy
T use at the same time as
the Quadra)? Or just plain upgraded your machine?

t be circumvented, and
s hassle-free,

Cheers,

                            / h+

- --
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --

   NetHack 3.1: Any Year Now.

+++++++++++++++++++++++++++

From: [e-mail]
Date: 18 Dec 92 19:04:18 +1300
Organization: University of Otago, Dunedin, New Zealand

In article <[e-mail]>, [e-mail] (Tim Dierks, software saboteur) writes:

> continued in the Mac.  The biggest single problem was serviceing
> these machines; if the PROM blew, you had to special-order a
                     ^^^^^^^^^^^^^
The PROM blew? Just blew? Did this actually happen? I'm amazed: I though PROMs
(not EPROMs, mind you) were extremely reliable, more so than most components on
a typical motherboard. Did Apple have some special problems with them?

I would have thought the Lisa problem would happen when for whatever reason it
was necessary to swap the motherboard, at which point the soldered-in PROM
would be impracticable to remove...

Michael(tm) Hamel
Analog Digital Instruments, Dunedin, New Zealand.

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Fri, 18 Dec 1992 21:33:02 GMT

[e-mail] writes:
>[e-mail] (Tim Dierks, software saboteur) writes:
>
>> continued in the Mac.  The biggest single problem was serviceing
>> these machines; if the PROM blew, you had to special-order a
>
>I would have thought the Lisa problem would happen when for whatever reason it
>was necessary to swap the motherboard, at which point the soldered-in PROM
>would be impracticable to remove...

My two bits on copy protection:  I have a Lisa sitting in my closet,
complete with the manuals and original disks for LisaWrite, LisaDraw,
LisaPaint, LisaDoodle, and LisaYodel.  I also have a defunct 4.8-meg
ProFile hard drive, which presumably has all that software on it, but
which stubbornly refuses to work.

The disks won't reinstall;  I think the installation process marked the
disks as "already installed," and it refuses to do it again.  At least,
that's what a Lisa reference book says (yes, I actually found one at a
bookstore!).

So, I bought $10,000 (1983 dollars) worth of hardware, probably several
thousand in software, and a cool hard drive for under $15, and I got
rooked.  It's worth whatever a scrap metal dealer will pay for it (and,
despite that solid lead case, I don't think I'll get $15).

Even if I got the hard drive working, I'd have to call up the software
company and ask them to send me replacement disks in exchange for the
ones I have...anyone think I'll get them?
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 "As you should know by now, we're strong believers in the Apple II
  and always will be.  But we can't ignore reality forever."
    - Tom Weishaar

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 19 Dec 92 03:01:59 GMT
Organization: Taligent, Inc.

In article <[e-mail]>,
[e-mail] (Edgar Matias) wrote:
>
> Isn't that the idea?  If you are going to have a copy protection scheme,
> I'd think that would be the best type.  Least amount of hassle for the
> user, yet still protects the software industry's interests.  Of course,

You'd think so, but I remember visiting a Lisa customer who had problems
because he had to keep track of which set of diskettes went with which
machine.

Larry Rosenstein
Taligent, Inc.

[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Matthew T. Russotto)
Date: 19 Dec 92 03:04:55 GMT
Organization: Project GLUE, University of Maryland, College Park

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]>, [e-mail] (Tim Dierks, software saboteur) writes:
>
>> continued in the Mac.  The biggest single problem was serviceing
>> these machines; if the PROM blew, you had to special-order a
>                     ^^^^^^^^^^^^^
>The PROM blew? Just blew? Did this actually happen? I'm amazed: I though PROMs
>(not EPROMs, mind you) were extremely reliable, more so than most components on
>a typical motherboard. Did Apple have some special problems with
them?

I don't know about in the Mac, but blasting the P5/P5A PROM on the old
Apple II disk controller card was a fairly common occurrence.
- --
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

+++++++++++++++++++++++++++

From: [e-mail] (Niel Bornstein)
Date: Thu, 17 Dec 92 09:29:55 EDT
Organization: Heavy Objects R Us


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Michael Trevor CUTTER) writes:
>We are looking for a way to uniquely identify a Mac, probably one on a network,
>but not necessarily. Is the serial number or similar available somewhere in the
>ROMs or parameter RAM? (Highly unlikely, I know - specially since PRAM can be
>reset)


How about the AppleTalk address?  I know, they are assigned dynamically,
but if the network is mature it will stabilize.  Are machines being
added to or taken off the network a lot?

Or if it's a TCP/IP network, there's the IP address.

If they're not networked, I don't know.

Niel

|--------------------------------------------------------------------------
| Niel M. Bornstein                              chinchilla![e-mail] |
| 1352 North Morningside Drive               ...csn!sable!chinchilla!niel |
| Atlanta, Georgia  30306                 [phone]   [phone] |
- --------------------------------------------------------------------------|
| Opinions? I don't need no stinkin' opinions!                            |
|--------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Peter N Lewis)
Date: 21 Dec 92 05:39:52 GMT
Organization: NCRPDA, Curtin University

In article <[e-mail]>,
[e-mail] (Edgar Matias) wrote:
>
>
> > In article <[e-mail]>, [e-mail] (Roy Smith) writes:
> > >
> > > I personally think it was a major mistake for Apple
> > > to not have put some sort of machine-readable serial number in each machine.

> > Can you say "copy protection"...?

> Isn't that the idea?  If you are going to have a copy protection scheme,
> I'd think that would be the best type.  Least amount of hassle for the
> user, yet still protects the software industry's interests.  Of course,
> if you're in the habit of pirating software maybe it's not in your
> interests...
>
> I'm a little surprised that the software industry hasn't latched onto
> this idea and lobbied hard for it.  It seems like the ideal solution
> to software piracy.  Of course, it wouldn't stop piracy entirely but
> it would certainly put a serious dent in it.

Isn't it clear why its not done?  If Apple put a serial number on the
machine, and people successfully copy protect their programs, the immediate
consequence of this is that the value of the machine drops a great deal.
All those users can't pirate the programs they want, so they stop buying
the machines, and buy other machines where they can get the programs
they want for free.  This may not be moral, but I haven't found much
connection between morality and reality.  Besides, its not Apple's
problem if people pirate (non-apple) software, quite the opposite,
Apple benifits by this.

I'm not condoning piracy - the world would probably be a better place
if their was no piracy, but the world would be better off if no one
went hungry as well, and neither of these outcomes are going to happen
any time soon, and the latter is far more important than the former anyway.

There have actually been a few examples of hardware with serial numbers
on them, but they've mostly gone out of business now...

Have fun all,
   Peter.

_______________________________________________________________________
Peter N Lewis <[e-mail]>             Ph: [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 22 Dec 92 06:36:00 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Peter N Lewis) wrote:
>
> Isn't it clear why its not done?  If Apple put a serial number on the
> machine, and people successfully copy protect their programs, the immediate
> consequence of this is that the value of the machine drops a great deal.
> All those users can't pirate the programs they want, so they stop buying
> the machines, and buy other machines where they can get the programs
> they want for free.  This may not be moral, but I haven't found much
> connection between morality and reality.  Besides, its not Apple's
> problem if people pirate (non-apple) software, quite the opposite,
> Apple benifits by this.

I agree that piracy is one of the things that made personal computers as
popular as they are.  Almost every _person_ I know who bought a machine for
themselves busted their bank on the machine and ran on pirated software
until they could afford to buy their software.  I personally have used many
pirated programs in order to evaluate them before buying.  It's how I got
to know so much about the machine and the software.

PCs sell because you can pirate when you need to.  Getting the work done is
the number one priority, isn't it?  ;)

Of course, I must point out that piracy is not a valid long term solution,
for all the obvious reasons.  You don't buy, we don't write.  Piracy as a
full-time policy is a self defeating proposition.  You've got to buy so
that the market works.

Jon

Squeeking for myself again and trying damn hard to fill my mouth with feet.

+++++++++++++++++++++++++++

From: [e-mail] (Noah Price)
Date: 23 Dec 92 19:33:56 GMT
Organization: (not the opinions of) Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Peter N Lewis) wrote:
> Isn't it clear why its not done?  If Apple put a serial number on the
> machine, and people successfully copy protect their programs, the immediate
> consequence of this is that the value of the machine drops a great deal.
> All those users can't pirate the programs they want, so they stop buying
> the machines, and buy other machines where they can get the programs
> they want for free.  This may not be moral, but I haven't found much
> connection between morality and reality.  Besides, its not Apple's
> problem if people pirate (non-apple) software, quite the opposite,
> Apple benifits by this.

Sorry to burst your bubble.  As developers who watch the newsletters know,
Apple is quite active in anti-piracy education efforts.

People have already talked about why the simple serial number is more
trouble than it's worth for copy-protection (or more accurately, for
execution control).  More advanced devices, yes those ugly dongles, solve
some of these problems by adding some intelligence.  More important, they
can move from machine to machine so you don't have to go through
administrative back-flips when you service, upgrade, or replace a machine.
Newer ones can even key multiple application, so you don't get a
dongle-tree growing off your keyboard.

I personally don't think these should be used at all though, except for
mega-buck vertical market applications, or software sold in countries with
little or no respect (or legal clout) for copyright and piracy protection.

noah

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[e-mail]                                 Macintosh Hardware Design
...!{sun,decwrl}!apple!noah   (not the opinions of) Apple Computer, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Robert Murphy)
Date: 22 Dec 92 20:33:03 GMT
Organization: Informix Software, Inc.

[e-mail] (Peter N Lewis) writes:
>There have actually been a few examples of hardware with serial numbers
>on them, but they've mostly gone out of business now...

Actually, most of the dedicated Unix workstations out there - including
Suns, NeXTs, and IBM RS/6000's - have serial numbers in a PROM on the
motherboard.  (We're not talking Macs running A/UX or PClones running
SCO Unix here.)  For more information, log into your nearest such
workstation and type "man hostid" at the shell command prompt.

Regards,
Bob Murphy

+++++++++++++++++++++++++++

From: [e-mail] (Roy Smith)
Date: 24 Dec 92 01:28:40 GMT
Organization: New York University, School of Medicine

[e-mail] (Robert Murphy) writes:
> Actually, most of the dedicated Unix workstations out there - including
> Suns, NeXTs, and IBM RS/6000's - have serial numbers in a PROM on the
> motherboard.

    Any box that comes with a built-in ethernet port has the moral
equivalent of a machine-readable serial number -- the ethernet 6-byte
hardware address.
- --
Roy Smith <[e-mail]>
Hippocrates Project, Department of Microbiology, Coles 202
NYU School of Medicine, 550 First Avenue, New York, NY 10016
"This never happened to Bart Simpson."

+++++++++++++++++++++++++++

From: [e-mail] (Freek Wiedijk)
Date: 25 Dec 92 17:04:41 GMT
Organization: Department of Philosophy, University of Utrecht, The Netherlands

[e-mail] (Peter N Lewis) writes:
>If Apple put a serial number on the
>machine, and people successfully copy protect their programs, the immediate
>consequence of this is that the value of the machine drops a great deal.
>All those users can't pirate the programs they want, so they stop buying
>the machines, and buy other machines where they can get the programs
>they want for free.

Yes!

That's why one of my friends (hi Jos!) bought a 486 machine and
advocated me to do the same (never!).  "Pirating software for it is
much easier because there are far more people to copy software from."

Yet another reason why Intel machines are more popular that Macs.
Not only is the hardware cheaper, the software is also cheaper...

Freek
- --
Third theory of Phenomenal Dynamics:  The difference between
a symbol and an object is quantitative, not qualitative.

+++++++++++++++++++++++++++

From: [e-mail] (Freek Wiedijk)
Date: 25 Dec 92 17:11:09 GMT
Organization: Department of Philosophy, University of Utrecht, The Netherlands

[e-mail] (Jon Pugh) writes:
>Of course, I must point out that piracy is not a valid long term solution,
>for all the obvious reasons.  You don't buy, we don't write.  Piracy as a
>full-time policy is a self defeating proposition.  You've got to buy so
>that the market works.

Pirating business software for home use will obviously not suffer from
this problem.  Anyone want to run Excel on their home machine?

Freek
- --
Third theory of Phenomenal Dynamics:  The difference between
a symbol and an object is quantitative, not qualitative.

+++++++++++++++++++++++++++

From: [e-mail] (Robert Murphy)
Date: 23 Dec 92 21:15:03 GMT
Organization: Informix Software, Inc.

[e-mail] (Dana S Emery) writes:

>In article <[e-mail]>,
>[e-mail] (Edgar Matias) wrote:

    [discussion of serial numbers and copy/execution protection deleted]

>OK, now that would either be in a custom chip or in the Roms, but in either
>case it would be WELDED on to the logic board, right?

Nope.  It would be in some sort of PROM ("Programmable ROM") chip which
is plugged into a socket, not welded.  The only information recorded in
this PROM chip would be the serial number, which would be recorded into
the chip at the factory.  Presumably Apple would use a type of ROM that's
not erasable or reprogrammable.

>Now what happens when a logic board needs service?  Since the board now
>must stay with the machine, you have just forced all apple dealers to
>perform componant level diagnosis and repair, this is a dramatic change
>from present policy, and on which APple is likely to regard as a giant step
>backward.

The person servicing the computer pulls the PROM chip out of the socket on
the old motherboard, and puts it in the socket on the new motherboard.

>Oh, and just how would one deal with a faulty Rom chip, or a ROM upgrade
>(remember the SCSI problems in the first and second versions of the 128k
>roms?).

Since this is on a separate chip from the ROMs you're talking about, it's
not a problem.  I suppose you could get a faulty PROM, but that would be
easily replaceable.

There are, by the way, a couple of flaws with this system.  First, if you
wanted to make machine A look like it's machine B, you could crack the
case and swap the serial number PROMs.  This is not really a problem as
far as software publishers are concerned, though, because they mostly are
concerned about people running multiple copies of their program simultan-
eously on different machines, and PROM swapping still only lets you run
the program on one machine at a time.  Second, and more of interest to
pirates, is the possibility of duplicating the PROM chips.  I'm sure there
would be ways to prevent this, though, such as adding some extra functionality
to the PROM chips so that they do more than act as PROMs, and so you
couldn't just go out and buy blank PROMs and put a serial number in them
and expect them to work.

>Dana S Emery <[e-mail]>

Bob Murphy
[e-mail]

P.S.  I've had to think about this stuff a lot because in the last four
years, I've written execution control code for several programs on Macs and
DOS machines using three different kinds of dongles from two different
manufacturers, and I am talking to two potential clients about doing the
same thing for them.  (For those unfamiliar, a "dongle", or "hardware lock",
is a device that you attach to some port on a computer, typically ADB on
the Mac or a parallel port on DOS.  When a protected program is running,
it can find out if the dongle is attached to the computer it's running on,
and refuse to execute if the dongle is missing.  You can copy such programs
onto 4,000,000 floppies if you want, but they'll only RUN on a computer with
the correct dongle attached.  That's why it's called "execution control",
not "copy protection".)  By the way, none of these programs have been the
sort of thing college students would likely want to pirate; rather, they've
been vertical market applications in the $3,000-$15,000 price range that
are aimed at corporations with enough money that they shouldn't need to
pirate software - but nonetheless, some of them have tried...

+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 25 Dec 92 00:00:36 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Niel Bornstein) writes:
>
> In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Michael Trevor CUTTER) writes:
> >We are looking for a way to uniquely identify a Mac, probably one on a network,
> >but not necessarily. Is the serial number or similar available somewhere in the
> >ROMs or parameter RAM? (Highly unlikely, I know - specially since PRAM can be
> >reset)
>
>
> How about the AppleTalk address?  I know, they are assigned dynamically,
> but if the network is mature it will stabilize.  Are machines being
> added to or taken off the network a lot?

If you have PowerBook users, there very well may be many machines
coming and going from your network on a regular basis.

You might take the approach that Apple used with Aliases.  They store
a number of tidbits of information when trying to track a file (things
like name, location on a volume, create date, etc) and use a number
of rules to figure out if that file out there that looks like the
one we want is *really* it.

You might use something like a combination of AppleTalk address, user
name, machine name, machine type, boot volume create date, etc.

Then you use some rules like:

(1) if only AT address changed, figure it's the same machine as yesterday.
(2) if only user name changed, figure it's the same machine asas yesterday.
(3) if only the boot volume create date changed,  figure it's the same machine as yesterday.
(4) etc.

If you are careful in how you choose these variables and rules you
will probably do OK.  You still may want to through up your hands
every now and ask the user (as they do with Aliases).

Good luck...

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --                      --   San Jose, California USA 95117
- --  Drop by booth #4463 --   voice: [phone] fax: [phone]
- --  at MacWorld Expo/SF --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (James W. Melton)
Date: 29 Dec 92 07:06:30 GMT
Organization: "Lockheed Austin Division, 6800 Burleson Rd, Austin, TX 78744

In article <[e-mail]> [e-mail] (Roy Smith) writes:
>
>    Any box that comes with a built-in ethernet port has the moral
>equivalent of a machine-readable serial number -- the ethernet 6-byte
>hardware address.

I have bad news for you: The ethernet address is set in software.
The high-order portion of the address is supposed to reflect the
manufacturer, and the low-order portion is supposed to be machine
unique (a serial number), but this is not accomplished in hardware
NECESSARILY.

There is NO fool-proof method of machine identification short of
the ubiquitous "dongle" method.

"Build a system even a fool can use, and only a fool will use it."

+++++++++++++++++++++++++++

From: [e-mail] (Robert Murphy)
Date: 29 Dec 92 22:23:02 GMT
Organization: Informix Software, Inc.

[e-mail] (Niel Bornstein) writes:


>In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Michael Trevor CUTTER) writes:
>>We are looking for a way to uniquely identify a Mac, probably one on a network,
>>but not necessarily. Is the serial number or similar available somewhere in the
>>ROMs or parameter RAM? (Highly unlikely, I know - specially since PRAM can be
>>reset)


>How about the AppleTalk address?  I know, they are assigned dynamically,
>but if the network is mature it will stabilize.  Are machines being
>added to or taken off the network a lot?

A Mac's AppleTalk address can potentially change every time the machine is
booted.

>Or if it's a TCP/IP network, there's the IP address.

If you're serious about uniquely identifying the Mac (e.g. tying program
execution to a particular Mac), this is a very ineffective way of doing
it.  All you have to do is change the IP address of the Mac.  If it would
conflict with another Mac on the network, pull your Mac off the network.

A client of mine has a product with execution control tied to an IP
address.  (This is on a Sun, by the way.)  You get the program, call in
with the invoice number and IP number, and get an authorization code.
At one of their customers, somebody called in with IP number
129.blah.blah.blah and got an auth code.  Then somebody else called in
with the same invoice number and a different IP number.  Big fireworks!
"Why, 129.blah.blah.blah isn't even on our network!"  Turned out it was
one of IP numbers you get on out-of-the-box Suns.  As best as they can
tell, somebody intercepted the software in the customer's mailroom, called
and got the auth code, and then put the software back in the mailroom.
The pirate can run their Sun normally on the company's network, and when
they want to run this software, they unhook the ethernet connector,
change the IP number, and reboot the Sun.  My client got ripped off for
a $10,000 software package.

Needless to say, this client has changed his procedure for issuing auth
codes.

Regards,
Bob Murphy

+++++++++++++++++++++++++++

From: [e-mail] (Noah Price)
Date: 4 Jan 93 18:23:50 GMT
Organization: (not the opinions of) Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (James W. Melton)
wrote:
> In article <[e-mail]> [e-mail] (Roy Smith) writes:
> >    Any box that comes with a built-in ethernet port has the moral
> >equivalent of a machine-readable serial number -- the ethernet 6-byte
> >hardware address.
>
> I have bad news for you: The ethernet address is set in software.
> The high-order portion of the address is supposed to reflect the
> manufacturer, and the low-order portion is supposed to be machine
> unique (a serial number), but this is not accomplished in hardware
> NECESSARILY.

I know "any box" wasn't limited to a Macintosh, but all the Macs with
on-board ethernet have a unique address in a PROM.

noah

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[e-mail]                                 Macintosh Hardware Design
...!{sun,decwrl}!apple!noah   (not the opinions of) Apple Computer, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Matt Slot)
Date: 6 Jan 93 00:50:12 GMT
Organization: University of Michigan, CAEN

If you need to do this from an application, there are several tricks you
can try. Use  TickCount() to get a long, try Random() (one in 4 billion
chance of duplication), or the
initialization time of the Boot volume.

Not foolproof, but pretty good.

Matt

---------------------------

End of C.S.M.P. Digest
**********************